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ABSTRACT 


This dissertation focuses on the Stantec-ZEBRA computer from the 1950s designed by 
Willian van de Poel. This computer is a mystery to contemporary computer scientists but 
this is a computer that was used to make many important calculations, such as calculating 
the trajectory with which an aircraft has to take in order for it to land safely on the runway. 
At that time, calculations would take hours of number crunching by this computer but with 
today’s computers and resources it can be done within the blink of an eye. 

The goal is to try and discover how this ZEBRA worked, how it performed its calculations, 
and what type of programming language was used to write programs that ran on this 
computer. This is achieved by creating new programs written in a language that was 
compatible to the computer. These programs will be created for the ZEBRA emulator 
created by Don Hunter using the Simple Code programming language. 

This document is divided into five parts. The first part focuses on the history of early 
computers focusing mainly on the Stantec-ZEBRA and emulators in general. The second 
part is based on the authors interview with Rod Delamere, one of the people to use the 
actual ZEBRA computer in the 1950s. The third part dives deeper into the details of the 
computer giving a literature review and describing emulators and the emulation process. 
The fourth part illustrates the project development process, giving the methodology that is 
used to prepare this thesis and specifying the technology used to develop the programs to 
run on the emulator. The fifth and final chapter gives the outcome of the whole process and 
stating the challenges that were met and how they were overcome and giving a final 
conclusion to the thesis itself. 
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1 INTRODUCTION 


It is good practise to preserve and maintain records of technological advancements as they 
are a symbol of achievement and breakthrough. As new, faster and cheaper software and 
hardware is created society tends to forget the origins of these technologies, which are 
rendered obsolete. Digital preservation comes into play by trying to conserve these 
achievements by documenting them. Digital preservation in itself is a formal endeavour to 
ensure that digital information of continuing value remains accessible and usable (User, 
2016). 

(The encyclopaedia of computer languages, no date) In 1976, at the History of Computing 
Conference in Los Alamos, Richard Hamming described why we might be interested in the 
history of computing: "we would know what they thought when they did it". We need to 
know why the people who designed computers thought the way they did. When they 
designed them, they made conscious choices, which we have to live with. And they made 
those choices for a wide variety of reasons, as many as the reasons for which they felt the 
need to create a computer in the first place. By knowing this, we can see the path in which 
those people had envisioned for the future and what expectations they had. As the world 
becomes more dependent on software and computers we find that the core of that software 
and computer still remain a mystery to even their users, the programmers. By paying 
attention to the origin, rise and fall of each of the computers, we may learn why the 
inventors made their decisions. 

Many computers and programs have been created since the start of 1940 and the Electronic 
Numerical Integrator and Calculator (ENIAC) is commonly called the first computer 
because it was the first fully functional electronic computer. Computers during this time 
would fill an entire room needing ventilation and many vacuum and mercury tubes to run 
and store programs in. As big as they were, they would probably compute simple 
calculations or to output data on paper tape which will need further interpretation in the 
end. Apart from having these computers, this did not stop other people from designing and 
coming up with smaller and more powerful computers of their own. 
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This thesis will focus on one of the early computers known as the Stantec-ZEBRA. This 
computer is one of the many that were designed during the period of 1952-1958, including 
the EDSAC and Manchester “Baby” commonly known as Small Scale Experimental 
Machine. The ZEBRA is among the first commercial computers to be developed for use in 
Universities, Technical Colleges and Eaboratories. Before the Stantec-ZEBRA, computers 
were only used by scientists and access was restricted. Willem van der Poel made the design 
of the ZEBRA as his PhD thesis in 1956 at the University of Amsterdam. ZEBRA is an 
acronym for the Dutch words Zeer Eenvoudige Binaire Reken-Automat, which means 
Very Easy Binary Calculating Machine (Society, no date). 

Around 58 of van der Poel’s computers were built at the Standard Telephones and Cables 
company in Newport and most of them were shipped out to other countries and a small 
number was left in Wales the area of its birth. One of the remaining latest version of the 
ZEBRA computer is housed at the National Museum of Wales, and the aim of this project 
is to investigate the Stantec-ZEBRA emulator and bring back its performances and 
activities it used to carry out during its time. 

1.1 Emulators 

The Stantec-ZEBRA is among the first electronic computer to be used outside the scientific 
area and introduced into the academic and economic areas. The latest ZEBRA is held at 
The National Museum of Wales and it is not in functional condition. Other early computers 
such as the Small Scale Experimental Machine (SSEM) also known as the Manchester 
“Baby” and the Electronic Delay Storage Automatic Calculator (EDSAC) have been 
revived and maintained electronically through the use of emulators. These emulators run 
the programs that were previously run on the early computers. Having an emulator allows 
the current generation to have a feel of how the pioneering computers worked since modem 
computers have abstracted a lot of information. See figures 1 and 2 below showing the 
Manchester “Baby” and the EDSAC emulators respectively. 
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Figure 1.1: Manchester "Baby" emulator. Image source http://www.clavidsharp.com/babv/ 



Figure 1.2: EDSACemulator. Image source http://www.computerconservationsocietv.ora/software/edsac/base.htm 

In addition, projects are underway to revive the hardware components of these early 
machines and one example is of the EDSAC Project at the National Museum of Computing 
in United Kingdom. Unfortunately, the Stantec-ZEBRA computer is in a condition that 
needs repair and the focus of this project is to help motivate the revival of this computer 
through giving a detailed understanding of the functionality of this early computer. 
Eortunately, enough, there exists an emulator for the ZEBRA and is available for download 
on the Computer Conservation Society website. Emulation refers to the ability of a 
computer program in an electronic device to imitate another program or device. 

Some other programs of similar nature are BlueStakes, Andy and DOSBox. These are 
examples of the many, successful emulations that have happened up to this day. Blue Stakes 
and Andy are programs that emulate the Android mobile device so you can run applications 
such as WhatsApp and Candy crush on your computer as if it were a mobile or tablet. 
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DOSBox emulates the command-line interface of DOS and you can enter commands and 
run programs from there. 



Figure 1.3 BlueStakes. Image source htto://www.download-bluestacks.com/ 



Figure l.AAndy. Image source http://aetintopc.com/softwares/emulators/andv-android-emulator-free-download/ 
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=s J. 


For o short introduction for neu users type: INTRO 
For supported shell commands type: HELP 

To adjust the emulated CPU speedy use and 

To acti^/ate the keynapper 

For more information read the README file in the DOSBox directory. 
HAUE FUN? 

The DOSBox Team http://iiJuu.dosbox.com 


DosBox Turbo for Android 

D^i^.>e C is mounted as local directory /mut/sdcard/ 
C:\>S 


Figure 1.5 DOSBox 


1.2 Aims 

The primary focus of this research project is: 

1. To find and bring together information that enables us to reconstruct the operation 
of an early computer, the Stantec-ZEBRA. 

2. To raise awareness of the value of reviving old machines and legacy machines such 
as the Stantec-ZEBRA and to develop an appropriate methodology for such 
conservation. 

1.3 Objectives 

1. To master software engineering tools and methods of programming in Simple Code 
Eanguage. 

2. To write custom code in Simple Code Eanguage that runs on the emulator for the 
ZEBRA computer. 

3. To understand fine details of computer architecture and memories and machine 
code programming. 

4. Be able to interpret some sample Simple Code programs written by Don Hunter 
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1.4 Methodology for the Stantec-ZEBRA 

A work breakdown structure is the decomposition of the total scope of work to be carried 
out in order to accomplish the project objectives and create the required deliverables. By 
splitting up the work, a clear path for accomplishing the objectives is laid out in a clear 
manner. Below is the WBS that will be followed throughout the project development 
process. 

The work structure of this project intends to start with learning the commands that were run 
on the Stantec-ZEBRA machine. How those commands executed the input that the 
computer was given and to study the declarations and definitions that are found in the 
commands. After learning the commands, the second step will be to find the language that 
is supported by those commands. Languages such as Simple Code and Normal Code were 
in existence during the 1950s and the target is to try and write a program in Simple code 
that will be able to run on an emulator of the ZEBRA that was designed by Don Hunter. 

The best explanation of Normal Code is given in an article called Stantec-ZEBRA and it 
mentioned that, the structure of the Normal (machine) Code is based on a novel idea. Single 
letters specify basic operations such as add, test, store; but there are 15 such letters (called 
function digits) and these may be used in any combination so that the programmer may 
construct thousands of different instructions. It is possible to instruct the machine to add, 
transfer, shift, modify and test "all at the same time", thus making the effective speed of 
operation of the computer greater than the intrinsic electronic speed would suggest (PartlV, 
no date). 

At the same time of learning the programming language to be used to create the emulator 
and its commands, designing and writing of sample programs will also take place. By 
looking at other similar emulators like the Manchester baby and EDSAC, design structure 
of the ZEBRA can be deduced. After learning and design, implementation can then take 
place and the work put in will be on accomplishing a functional program written in Simple 
Code that runs on the ZEBRA emulator. 

On the other side, working concurrently with code learning and program writing, focus will 

be also put on writing the project documentation and possibly having a tour to see the 

7 


UNDERSTANDING THE STANTEC-ZEBRA 




hardware of the existing ZEBRA machine. After that the priority will be to raise awareness 
on the importance of 



Figure 1.6: Work breakdown structure for ZEBRA project 


having to revive the computer, its importance and how this will benefit the computing 
society as a whole. 


1.5 Project Scope 


The scope of a project defines the boundaries of a project. The information that is going to 
be delivered and to what extent and what is going to be designed, what it will do and what 
it will not do is defined as the scope of a project. The scope of the project is on: 


1. Early machine architecture 

2. Virtual machines 

3. Emulators 
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1.6 Requirements 

Defining requirements specifies the capabilities, features or attributes of the project’s 
deliverables. The requirements are given below stating what the emulator will look like, 
what kind of computations it will perform and which type will be created. 

Table 1.1: Project Requirements 


Requirements 

Description 

Simple Code program 

A Simple Code program must be written using the command 

and routine functions provided from sample programs that 

come with the emulator 

Must run on the ZEBRA 

emulator 

The written program must be able to run on the emulator to 

show that the student has understood the programming 

language 

Key words to be used as 

commands to the 

program 

As illustrated in 

httD://www.memtsi.dsi.uminho.Dt/ocr/simDle code zebra.ndf 

Simple Code was used to program the machine because it was 

more simplified by using key words in replace of functions 

Interpret sample 

programs 

Student must be able to explain the code that was written for 

some sample programs written for the ZEBRA emulator 


The above requirements may be altered during the course of development to further 
improve the final project. 

SUMMARY 


Part I of this thesis introduced the Stantec-ZEBRA computer, its background and the 
inventor van der Poel a Dutch computer scientist. The description was brief leaving room 
for more explanations in detail in Part II. The main focus was on specifying the aims and 
objectives of this project to make a clear demarcation on the path that this project will take. 
The goal is to try to meet these objectives as this will signify the success or failure of this 
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project. The plan on how to tackle this project is also given in the form of a WBS. This 
helps to break down and organise activities. By doing this it will make time management 
more easy as the student only has to follow the order that he/she has designed in order to 
finish the project on time. A list of the scope of that the project will be given and finally 
the requirements are given as the key milestones of the project, what is required by the 
users of the system. 



Figure 1.7: Willem van der Poel, the creator of the ZEBRA computer. Image source 
httos://www.l<naw.nl/nl/leden/leden/4658 



Figure 1.8: A Stantec-ZEBRA installation in Liverpool, England, used by an animal foodstuffs manufacturer for 
computation of multiple combinations of vitamin contents against available ingredients at varying prices. Image source 
http://archive.computerhistorv.ora/resources/text/Standard/Stantec.Zebra.1961.102646082.pdf 
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Part II 

The Stantec-ZEBRA and its 
Interpretation 


> Chapter 2: UNDERSTANDING 
THE ZEBRA: AN INTERVIEW WITH 
ROD DELAMERE 

> Chapter 3: HOW THE ZEBRA 
WORKS: AN INTERVIEW WITH ROD 
DELAMERE 

> Chapter 4: SIMPLE CODE AND ITS 
INTERPRETATION 
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2 UNDERSTANDING THE ZEBRA: AN 
INTERVIEW WITH ROD DELAMERE 


The main idea of the maehine is to eeonomise as far as possible on the number of 
eomponents by simplifying the logieal strueture. For example, multiplieation and division 
are not built in but must be programmed (Compiled, Newell, and Bell, 1971). 

On the 27* of August 2016 an interview with Mr. Delamere was held by the researeher at 
his residence in Cardiff. Mr. Delamere is one of the individuals to have used the computer 
during the 1950s. This interview was carried out in order to get first-hand information on 
what was and how the machine worked. Mr. Delamere is in possession of a counter book 
that he used during his University days in the 1950s. In this book he has some Simple Code 
examples of programs that used to run on the original ZEBRA computer. 

Mr. Delamere described the ZEBRA as a simple calculator and reiterated that although they 
used Simple Code language to write programs that will be put in the machine in the form 
of paper tape, the language was all not so simple to understand. “The language was called 
Simple Code, but no, it was not that simple”. According to Mr. Delamere, he once used the 
ZEBRA machine to calculate the possible trajectory that an aeroplane would use in order 
for it to land safely without any problems. This calculation would take up to 5 hours on the 
ZEBRA whereas the time that a plane would take to land in real time was less than 5 min. 

A set of equations were internally embedded into the computer and a set on key words, T, 
LO, .... and Y, were used to code the input program. This program was written at the 
Glamorgan College of Technology in Treforest and the program was transferred onto the 
paper tape and this paper tape was taken to the Standards Telephone Cables where the 
computer was and this was input to the machine and the output was given by a tele printer 
that punched new holes on the paper tape. 

The main problem with the ZEBRA was that it had no way of error handling or even giving 
flags of messages when an error had occurred or what had caused it. The computer’s way 
of signalling an error was that, during its execution of the paper tape, when it encountered 
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an error of some sort, be it a misplaced value or a missing value, the computer just halted 
where it encountered the error. This was the only way that one could tell that there was a 
problem in executing the code. This was not of much help because an individual would not 
know what caused the problem and how to even fix it. The only thing that they could do 
was to check where the tape stopped and trying to find out what values were represented at 
that point and what could have caused the machine to stop. 

This was the main problem when it came to using the computer stated Mr. Delamere. When 
this happened, you had to go back to the College and rewrite your code paying special 
attention to the point where the computer stopped. This was a big inconvenience to using 
the machine and this meant that students had to wait for a week to go back to Standard 
Telephone Cables to use the computer again. 
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3 HOW THE ZEBRA WORKS: AN 
INTERVIEW WITH ROD DELAMERE 


The ZEBRA is a calculator that was used to make simple calculations. Although, there 
exists an emulator for the computer being hosted by the Computer Conservation Society, 
this emulator seems to be an improvement on the original computer. Mr. Delamere’s 
notebook contains some example programs that he used to run on the original computer 
together with the results that these equations would output on the tele printer and on the 
paper tape. 

Rod Delamere’s Compute lO’^ from approximate number (1 + ax + bx^ + cx^ + dx"^ + ex^)^. 
Given constants 

Y Be ready to accept 'simple code'. 

LO Read e => (0), d => (1), c => (2) , b => (3) , a => (4) . 

(Ql) Z Stop 

TlOO (A) => (100) 0 => (A) 

L6 Read xi => 6 

+05 Set count to 5 i.e. (a) => 6, 0 => a. 

AR e => (A) (exi + a) (exi + d) x + c 

V6 exi => (A) (exi + a)x etc. 

+ 1 (a) + 1 => a (|3) + (y) => P compare (a) with (s) 

A5 ({[(cxi + d)X + c]xi + b}ei + a)xi + 1 

UlO (A) => (10) (A) remaining 

VIO (A) 2 => (A) 

Z9 C.R.L.F. 

Z8 Print contents of (A) 

XI Jump to Ql 

YOO Begin execution at Y 
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The code above computed the results of 10’‘ using the equation (1 + ax + bx^ + cx^ + dx"^ + 
ex^)^. This program is known as Simple Code and it produces the computation of 10’‘ five 
times. This is achieved by the line +05 which sets count to 5. The parameters for a, b, c, d 
and e are (+1.15138424, +0.66130851, +0.26130650, +0.05890681, +0.02936622) 
respectively and the x values are (+0.5, +0.7, 0.25). The output was in the form of tele 
printer and produced the values (+0. 316665943 + 1, +0.501956281 + 1, +0.1779911374 + 
1) together with a paper tape output that is given at the appendix section of this 
documentation together with other examples. 

The computer had a tube that acted as the output window and this valve would only mark 
memory locations indicating which area contained a value and which one did not, using the 
(. and !) symbols. The (.) means off or empty no value is present in memory and the (!) 
means on and a value is present in memory This was the only output available and this did 
not give away the value that was stored or whether it was a signed or unsigned value. That 
was one of the difficulties of using the ZEBRA computer. Debugging was made really 
difficult. Error handling was not even made easy at all. 

This computer computed mathematical calculations to precision but it had a main 
disadvantage which was that it took too long to compute the results. According to Mr. 
Delamere at one point it had to compute the crystallization of compounds that were used in 
chemical equations and it took 15 hours to come up with the results of one equation. The 
other disadvantage of the ZEBRA computer was that it used vacuum tube as those that were 
used in television sets during that period. These vacuum tubes were fragile and could often 
explode when the computer was turned on. This meant that the computer had to be left in 
its on state even for days so as to avoid the damage of these tube because if one was to 
malfunction it would take about a week to two to replace just one tube and this had an 
impact on the amount of time that the students will be allowed to use the computer. 

The ZEBRA also had a coiled transistor on each and every wire that transferred an electric 
current over the circuit board. This coiling made it easier to detect where a short circuit will 
have occurred. Other computers during that period had their transistors glued to the circuit 
board. This made it really difficult to identify where the short circuit will have occurred. 
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Apart from that, the time for repairs was reduced by a number of days but still was a lot for 
students to skip their chances of using the computer. 


UNDERSTANDING THE STANTEC-ZEBRA 


16 




4 SIMPLE CODE AND ITS 
INTERPRETATION 


Simple Code is a language that was developed to be a really simple form of code for a 
beginner with further ‘not-quite-so-simple’ facilities giving a comprehensive and flexible 
programming code (Ord-Smith, 1960). The only guide that is given to a Simple Code user 
is the fictitious store and registers which he/she can use. The way that these stores and 
registers work is similar to how the assembly language works. There are two special 
registers: 

i. An accumulator called A; 

ii. An accumulative multiplication register called B. 

There are also 6 special registers used for counting and order modification and these are 
called a, P, y, 5, s, 0. 

To input numbers in the computer you use the command Ln which means, 'read number 
into n’ and to input a group of numbers you use the instruction LOn, which reads the 
numbers in sequence putting them into n, n+1, n+2,... until a terminating Y is encountered. 
The same instruction also counts the numbers, placing the count in 5. The output 
instructions are Pn and POn and will be in floating-point form. 

4.1 Jump instructions and labels 

Simple Code instructions are normally executed in sequence because it is a one-address 
language (Ord-Smith, 1960). To jump out of sequence of the code, this is done with an 
instruction Xp meaning 'Jump to instruction location labelledp\ There can be any number 
of jumps backward or forward to a labelled point. A point may have more than one label 
attached to it but, the same label cannot be attached to two or more different points. When 
a jump takes place, the X instruction automatically records a note of the location next to 
which it occupies and this is called the return instruction and it can be picked up and placed 
in a specific location by the instruction XOp. 
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There are also two conditional jump or test instructions which are: 

• Ep: jump to location labelled p if (A) >= 0 otherwise proceed serially. 

• EOp: jump to location labelled p if (A) < 0 otherwise proceed serially. 


4.2 Input and execution indications 

A Simple Code program when punched on tape is always preceded by the letter Y. This is 
an indication to the computer to jump to the Simple Code interpretive input program and 
begin taking in Simple Code (Ord-Smith, 1960). There are so many ways to start the Simple 
Code program and some of them include: 

• Y: jump to S.C. input, clear labels, and begin input of instructions at the beginning 
of the instruction store 

• Yp: means begin input of S.C. without clearing labels at the point previously 
labelled p. 

• YOn: means begin input (no clearing of labels) of instructions at location n in the 
number store. 

Execution indication, YOO, means stop input and begin execution at the place given in the 
last input indication. Therefore, a very simple program will begin with Y and be terminated 
with YOO. 

To begin a cycle of instructions n times it is necessary to precede the block with +On and 
end it with +1. The operations in the block are then repeated n times after which the program 
proceeds serially. These commands use the special registers a, s, 0, 5. +On does the 
following: 

• The contents of register a are transferred unchanged to register 5: (a) preserved—► 5; 

• a is cleared; 

• The register s is set to n, the count limit 

• A return instruction is written into the register 0. 
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If there are instructions within the loop, the address of which will vary depending on the 
count, R is written before the address in those instructions. An example to sum the contents 
of locations 200, 201, ..., 299, the instructions required are: 

+ O100 

AR2 00 

+ 1 

The above code has the effect of placing the contents of 200 in A, incrementing by 1 (+1) 
and adding the contents of 201 to A, 100 times (+O100). The instruction is A200. +n (‘count 
with n at a time’) has the action: 

(a) + n —► a; 

Instructions of the form IRn mean the number that is in instruction location n + contents of 
special register a: {IRn = In + (a)). 

4.3 Simple Code in the Real ZEBRA 

The interpretive programs of the Simple Code occupy approximately 1000 locations of the 
real ZEBRA store, a magnetic drum of 8192 words capacity. All the interpretive programs 
and all the subroutines are completely ‘dead’, they have no ‘live’ locations and can be 
locked away at the end of the store where they will be read but cannot, without unlocking 
them, be overwritten accidentally (Ord-Smith, 1960). Simple Code instructions are partially 
interpreted during input and are translated by the input program into a Normal Code 
instruction pair; one called the address part and one the operation part. 

Instructions are classified into two types: 

• Extractive instructions and 

• Non-extractive instructions 

Extractive instructions must extract the number to work with before performing operations, 
for example A, S, V, D and - instructions. Non-extractive instructions have to perform their 
main operation before worrying about storage location of the number, for example U, T, L 
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and + instructions. Execution of a Simple Code instruction consists of first extracting the 
appropriate instruction pair and transferring them into the A and B accumulators of ZEBRA. 

A wide variety of problems have been programmed in Simple Code, including telephone 
traffic problems, cable calculations, aircraft flight calculations and integration, have 
demonstrated the flexibility of the code and the speed with which such problems could be 
tackled, and working on calculations involved in what are called uniformity trials for the 
determination of optimum plot size and shape. 



4.4 Stantec-ZEBRA 

Simple Code Instruction 


Code 




Arithmetic Instructions 



• 

An 

(A) + (n) 


A 

• 

Sn 

(A) - (n) 

—► 

A 

• 

Vn 

(A) * (n) 

—► 

A 

• 

Nn 

-(A) * (n) 

-► 

A 

• 

Dn 

(A) / (n) 

-► 

A 

• 

Tn 

(A)-^n 

0 —► 

A 

• 

Un 

(A)-^n 



• 

Hn 

(n)-^ A 



Accumulative multiplication instructions 


• 

Kn 

(n) -► 

B 


Eollowed immediately by: 



• 

Vn' 

(B) * (n') 

t (A) 

-► (A) 

• 

Nn' 

-(B) * (n' 

) t (A) 

-► (A) 

Also provided: 




• 

VOn 

(A) + (n)2 

_► 

A 

• 

NOn 

(A) - (n)2 

-► 

A 

Some of the common subroutines 

are given below. The full list is given at the Appendix 


section 


• Z stop, wait for dial or start key 

• Z7 test key U1 
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• Z8 print (A) in floating form 

• Z19 jump from Simple code to Normal code 

These are the most common commands and instructions used in the development of a 
Simple Code program. All input numbers in the ZEBRA and converted into floating point 
form for faster processing. This is how the machine is structured (Ord-Smith, 1960). 

SUMMARY 


Part II of this thesis focuses on the Stantec-ZEBRA computer in more technical detail. 
Interviews were held with a former user of the ZEBRA computer during the 1950s and he 
provided first hand source information in the form of his notebook exercises from College 
and these are presented in Appendix I. This information was the turning point in the 
development process of this project. This information gave much detail in how to write 
Simple Code programs. Together with the short paper written by Ord-Smith describing the 
Simple Code, it made it more easy for the student to grasp the techniques on how the code 
is written. More advanced sections where presented in van der Poel’s book The Simple 
Code for ZEBRA. 



Figure 4.1: Rod Delamere pictured in May 2008 with his programming exercise book from 1961 for the Stantec-ZEBRA. 
Image source http://www.swansea.ac.uk/librarv/archive-and-research- 

collections/hocc/peopleandreminiscences/reminiscences/roddelamere/ 
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Part III 

Software preservation and the Stantec- 
ZEBRA 


> Chapter 5: LITERATURE REVIEW 

> Chapter 6: EMULATION AND 
EMULATORS 
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5 LITERATURE REVIEW 

5.1 Introduction 

This section focuses on looking at similar works that were done throughout the years and 
to find out a relationship between the work of the student and that which was done before. 
This is a review of texts from scholars which includes the current knowledge including 
substantive findings, as well as theoretical and methodological contributions to a particular 
topic. By referencing to known scholars this will solidify the relevance of the project and 
to show that what is being done is not totally new but some people have done it or at least 
attempted to do it and evidence is supplied for it. 

5.2 Emulation vs Simulation 

In some regards, the words emulation and simulation can be used interchangeably but there 
is a difference between the two concepts. In order to successfully complete this project, the 
researcher had to clearly distinguish between the two terms so as to minimise ambiguity 
and demarcate the bounds and scope of this project. 

5.2.1 Emulation 

(Joshi, 1989) defined emulation as a means of operating close to real-time. An emulators’ 
goal is for it to replace the original for real use. An emulator uses the same processes to 
achieve its objective and is mostly made out of the same materials as the original. (Kulenov, 
2016) looks at emulation as a model of some system that captures the functional 
connections between inputs and outputs of the system, based on processes that are the same 
as, or similar to, those of that system, and that is built of the same materials as that system. 
(Kumaarr, 2014) is of the opinion that, in computing and electronics, an emulator is 
considered as a software or hardware which can imitate (duplicate) the behaviour and 
functionality of different software within another software/hardware platform. Emulation 
is best described as imitating a certain computer platform or program on another platform 
or program. In this manner, it is possible to view documents or run programs on a computer 
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not designed to do so. An emulator is itself a program that creates an extra layer between 
an existing computer platform “host platform” and the platform to be reproduced “target 
platform” (What is Emulation, no date). 

With emulation, one will be trying to match the exact performance, speed and ability of the 
original. With this in mind, emulation is slow and expensive to do. One has to properly 
match the inner behaviours of an original device. If it took time to boot up as a machine, 
then the emulator also has to take the same amount of time. For an emulator to be 
considered good enough, it must act as the original device and it must be able to run the 
same programs as its predecessor at the same speed and using the same amount of 
resources. 


5.2.2 Simulation 

Simulation is a way that mimics the activity of something that it is simulating. It appears to 
be the same as the thing being simulated. For example, the flight simulator "appears" to be 
a real flight to the user, although it does not transport you from one place to another. A 
simulator is an environment which models but cannot be substituted with real system (Joshi, 
1989). In more technical terms, a simulator is a model of a system that captures the 
functional connections between inputs and outputs of the system, but without necessarily 
being based on processes that are the same as, or similar to, those of the system itself 
(Kulenov, 2016). In a simulator, the operation of a targeted system is recreated to the best 
possible. The underlying mechanisms used to recreate the scenario may be the same or 
different from the original. A simulator sets up a similar environment to the original 
device's OS, but doesn't attempt to simulate the real device's hardware. Some programs 
may run a little differently, and it may require other changes (like that the program be 
compiled for the computer's CPU instead of the device's), but it's a close enough match that 
you can do most of your development against the simulator (Keyan, 2014). 

Simulation is mainly focused on trying to reproduce and what is being made can have the 
same look and feel even the performance but it is not the same as the original device. A 
good example of how and where simulators work is the flight, car and movie simulators. 
An individual can enter into a plane or car and inside of it you can find the steering wheels 
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and controllers and the screens that you look at will give the environment as if you were 
actually driving or flying and the simulator tends to shake and give an experience of being 
real but in actual fact it will be stationary. 

(Kulenov, 2016) gives a table that gives the distinctions between simulation and emulation 
in more technical details. 


Table 5.1: The difference between an Emulator and a Simulator, source The Open University, 2007 


Emulation/Emulator 

Simulation/Simulator 

The microprogram-assisted macroprogram 

which allows a computer to run programs 

written for another computer. 

One that simulates, especially an apparatus 

that generates test conditions 

approximating actual or operational 

conditions. 

Hardware, software or a combination of the 

two that enables a computer to act like 

another computer and run applications 

written for that computer. In the past, it was 

often a hardware add-on that actually 

contained an instruction execution module 

for the emulated computer. Today, 

“emulator” more often refers to software, 

which provides a translation layer from the 

emulated computer to the computer it is 

running in. The emulator may translate 

machine language, calls to the operating 

system or both. 

A broad collection of methods used to 

study and analyse the behaviour and 

performance of actual or theoretical 

systems. Simulation studies are performed, 

not on the real-world system, but on a 

(usually computer-based) model of the 

system created for the purpose of studying 

certain system dynamics and 

characteristics. The purpose of any model 

is to enable its users to draw conclusions 

about the real system by studying and 

analysing the model. The major reasons for 

developing a model, as opposed to 

analysing the real system, include 

economics, unavailability of a “real” 

system, and the goal of achieving a deeper 

understanding of the relationships between 

the elements of the system. 
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An emulator in computing duplicates 

Simulation can be used in task or 

(provides an emulation of) the functions of 

situational training areas in order to allow 

one system using a different system, so that 

humans to anticipate certain situations and 

the second system behaves like (and 

be able to react properly; decision-making 

appears to be) the first system. This focus 

environments to test and select alternatives 

on exact reproduction of external 

based on some criteria; scientific research 

behaviour is in contrast to some other 

contexts to analyse and interpret data; and 

forms of computer simulation, which can 

understanding and behaviour prediction of 

concern an abstract model of the system 

natural systems, such as in studies of stellar 

being simulated. 

evolution or atmospheric conditions. 

With simulation a decision maker can try 

out new designs, layouts, software 

programs, and systems before committing 

resources to their acquisition or 

implementation; test why certain 

phenomena occur in the operations of the 

system under consideration; compress and 

expand time; gain insight about which 

variables are most important to 

performance and how these variables 

interact; identify bottlenecks in material, 

information, and product flow; better 

understand how the system really operates 

(as opposed to how everyone thinks it 

operates); and compare alternatives and 

reduce the risks of decisions. 

Emulation is the process of mimicking the 

Simulation involves modelling the 

outwardly observable behaviour to match 

underlying state of the target. The end 

an existing target. The internal state of the 

result of a good simulation is that the 

emulation mechanism does not have to 
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accurately reflect the internal state of the 

simulation model will emulate the target 

target which it is emulating. 

which it is simulating. 

The goal of an emulation is to able to 

A simulation’s focus is more on the 

substitute for the object it is emulating. 

modelling of the internal state of the target 

— and the simulation does not necessarily 

lead to emulation. In particular, a 

simulation may run far slower than real 

time. 


The difference between the two, henceforth, is made easy going through the literature of 
different authors. As mentioned above, an emulator is mainly concerned in reproducing the 
actual device, behaviour, functionality and speed using materials or software similar to the 
original and the end result is a functional device, whereas, a simulator mimics the original 
concept and creates/models an environment same as what the device will encounter but this 
device cannot be used as a substitute for the real work. A simulators’ main purpose is for 
education and training. Giving you an environment that is the same as to what you expect 
and training you in advance before doing the actual thing in real life, just like first person 
shooter games for the army, it’s a training exercise to give you more information on how 
to operate during battle. 

This project is, therefore, focused on the Stantec-ZEBRA computer and by deducing the 
above information it can be found that it matches the criterion of a simulator. This is due to 
the fact that the software created by Don Hunter, although it is an exact replica, the time 
that was spent processing on original programs during the 1950s is more than the time that 
his emulator takes to make mathematical equations. Don Hunter’s emulator was designed 
to run on all operating systems including the Windows 7 and later versions. This is made 
possible through the use of a software called the DOSBox. This DOSBox simulates the 
DOS environment on the machine and from this environment the ZEBRA computer can be 
run without any problems. This DOSBox helps to compile the PASCAE code used to write 
the ZEBRA with ease and also gives the chance to enthusiastic programmers and scholars 
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to make changes and help improve the computer or learn the programmatic details of the 
machine (Computer conservation society, no date). 

This Stantec-ZEBRA runs the actual programs that were run on the original ZEBRA 
machine but with addition of some few lines of code which will be explained in later 
chapters. These programs were written in Simple Code and Normal Code which is similar 
to Sub Programming. Sample programs written in these languages are available. This 
program is software based only and hence any hardware will not be referenced to, however, 
in the near future other projects can be embarked on as to revive the hardware parts of the 
machine and have it up and running. An example of such an endeavour is the project to 
build, demonstrate and maintain a replica of the Small-Scale Experimental Machine 
(SSEM) - the world's first computer. This project is a currently undergoing activity and 
there are volunteers needed in helping to recreate the machine and having it up and running 
at the Eondon Museum. To learn more about this venture, visit these websites 
http://curation.cs.manchester.ac.uk/digital60/www.digital60.org/rebuild/ and 

http://www.cs.man.ac.uk/CCS/SSEM/volunteers/index.html . 

5.3 Our Digital Heritage 

Digital Preservation is the management and maintenance of digital objects which can be 
categorised into the files, or groups of files, that contain information in digital form, so they 
can be accessed and used by future users (Stuchell, 2013). This preservation of digital data 
leads to the upcoming generation’s heritage. This heritage is key to people knowing where 
they are coming from, where they are and where they are heading. There are so many events 
that are held over the world to celebrate our digital heritage and the recent one is the Digital 
Heritage International Congress held in Granada Spain from 28 September to 2 October 
2015. 

These events help to raise awareness and try to convince people to preserve data, whatever 
in its form because you never know when it will be needed in use and who it will help. 
Digital data is one of the most vulnerable forms of data due to the fact that if something 
happens to where it is stored, like a virus attack, the data will be corrupted, altered or 
completely lost. Recovery from such situations is really hard but there have been 


UNDERSTANDING THE STANTEC-ZEBRA 


28 






developments of many means of back up as a number of alternatives to CD’s, flash and 
external drives. The Cloud and Google drive are some of the few to mention where you 
store your digital information and there it is guaranteed safe from corruption and deletion. 
Apart from these there are organizations who specialise in the conservation of digital 
information and this section is dedicated in giving more insight on them and their 
importance as our digital heritage keepers. 

Founded in 1989, the Computer Conservation Society is a joint venture between the British 
Computer Society, the Science Museum and the Museum of Science and Industry in 
Manchester. This organization’s primary mission is to preserve historic computers, develop 
awareness of the history of computing, and encourage research. It runs many specialised 
projects, organise public lecture series, and publish a regular bulletin (Computer 
conservation society, no date). 

This organisation is focused on preserving digital data but in the form of application 
software. Apart from the Computer Conservation Society, there exist some organisations 
that are committed to preserving digital information. Some of them include: 

Table 5.2: Organisations concerned with preserving digitai information 


Digital Preservation (Library of Congress) 

httD://www.digitalDreservation.gov/ 

The National Digital Information 

Infrastructure and Preservation Program 

implements a national strategy to collect, 

preserve and make available significant 

digital content, especially information 

that is created in digital form only, for 

current and future generations. 

University of Kent UK mirror services 

httD://www.mirrorservice.org/ 

The UK Mirror Service provides a 

collection of mirrors of FTP, web and 

rsync sites of interest to academic users. 

The service is provided by the University 

of Kent's School of Computing. 
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Online Historical Encyclopaedia of 

Programming Languages 

httD://hoDl.info/ 

This site is concerned with the idea- 

historical treatment of the development 

of programming languages as a means of 

human expression and creation. 

httD://www.cs.man.ac.uk/CCS/ 


Software Preservation and Machine 

Emulation 

httD://sw.ccs.bcs.org/CCs/index.html 

In preserving software, the desire is to 

keep the source text so that the style of 

programming is visible, and to provide 

facilities for execution of the preserved 

software on widely available current 

platforms. Where source text is in a 

language unlikely to be widely known 

(often assembly language) the intention is 

to provide reference information to 

enable the source text to be understood by 

a reader with basic programming literacy. 


The (The encyclopaedia of computer languages, no date) states that in 1976, at the History 
of Computing Conference in Los Alamos, Richard Hamming described why we might be 
interested in the history of computing: "we would know what they thought when they did 
it". We need to know why the people who designed programming languages thought the 
way they did. When they designed languages, they made conscious choices, which we have 
to live with. And they made those choices for a wide variety of reasons, as many as the 
reasons for which they felt the need to create a language in the first place. 

We see that for every creation there is a reason behind, an influencing factor that drives 

individuals to do come up with better means and ways of solving particular problems. The 

invention of programming languages led to the creation of computers and these computers 

initially were huge, expensive to run in terms of resources and very difficult to use. As more 

and more individuals studied how these computers worked they found better ways and 

means of designing them in a new way, to be faster, able to store information electronically, 

to be compact and portable and eventually to interconnect and for the global village that we 
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have today. This whole process did not just happen within a day. It took years of studying, 
improving and reengineering for what we have at this moment to be what it is. 

The danger, however, is that technology is evolving at a fast pace and people are now more 
concerned than ever to keep up with the changing trends and tend to forget the later and it 
tends to be rendered obsolete. As mentioned by the (The encyclopaedia of computer 
languages, no date), as the world becomes increasingly and overwhelmingly dependent on 
software, we find that the core of that software - programming languages and systems - 
remain a mystery to even their users, the programmers. By paying attention to the origin, 
rise and fall of each of the languages we may learn why they made their decisions. 
(Santayana, 1905) also said, "...Progress, far from consisting in change, depends on 
retentiveness. When change is absolute there remains no being to improve and no direction 
is set for possible improvement: and when experience is not retained, as among savages, 
infancy is perpetual. Those who cannot remember the past are condemned to repeat it. In 
the first stage of life the mind is frivolous and easily distracted, it misses progress by failing 
in consecutiveness and persistence. This is the condition of children and barbarians, in 
which instinct has learned nothing from experience....". 

As mentioned above, if we cannot remember our past then we are condemned to repeat it. 
During the time of the creation of the first computer, they had their own view of the world 
and future than what this generation will be anticipating. By learning how they thought and 
what they were expecting to achieve you will have a foundation on which to build on that 
is solidified by ideas of the predecessors. Thus, this is the role of the Digital Preservation 
Societies and the Computer Conservation Society. These organisations are there to preserve 
the history of digital information, be it in text form or software form. The aim is to keep 
safe this information and archive it for future use or upgrade. 

The Computer Conservation Society in particular is focused on the preservation of digital 
information but in its software/application form. The society is dedicated to: 

• To promote the conservation of historic computers and to identify existing 
computers which may need to be archived in the future. 

• To develop awareness of the importance of historic computers. 

• To develop expertise in the conservation and restoration of historic computers. 
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• To represent the interests of Computer Conservation Society members with other 
bodies. 

• To promote the study of historic computers, their use and the history of the 
computer industry. 

• To publish information of relevance to these objectives for the information of 
Computer Conservation Society members and the wider public. 

This organisation is not centred on making profits and thus it is funded and supported by 
voluntary subscriptions from members, a grant from The Chartered Institute for IT (BCS), 
fees from corporate membership and members’ donations. The society is also home to some 
projects of rebuilding early computers and one of the noted on is the project to build, 
demonstrate and maintain a replica of the Small-Scale Experimental Machine (SSEM) - the 
world's first computer. Some other projects being undertaken include the Colossus Rebuild 
Project, Our Computer Heritage, creating simh tapes images from real tapes. The HEC 1 
computer and computer films and other media known to the CCS. Eor more information on 
these please visit http://www.computerconservationsocietv.org/special.htm . 

The Society is also home to the famous computers that have been the pioneers of all the 
computers that we have in our current day and age. The software is downloadable and 
sufficient documentation is given explaining how these machines work and what they were 
used for during their days. The softwares that are housed by the Computer Conservation 
Society are: 

• Manchester Baby (SSEM) 

• Cambridge EDSAC 

• Eerranti Sirius 

• Eerranti Pegasus 

• Stantec-ZEBRA 

• ICT/ICE1900 

• Elliott 903 

• Eerranti Atlas 1 

• MU5 

• KDE9 
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• LEO III 

One of the many aetivities of the Computer Conservation Soeiety is to develop and preserve 
software for historie eomputers, many of whieh have long sinee passed into oblivion. In 
order to make this activity meaningful and to allow for the possibility of writing new 
programs for dead computers it is sometimes necessary and always useful to implement 
emulators: programs which run within modem computers but which interpret programs 
written for the target machine and cause them to be executed in much the same way as the 
hardware of the original computers once interpreted the instructions of their programs and 
carried out those instructions (Computer conservation society, no date). 

5.4 Don Hunter's Stantec-ZEBRA emulator 

Don Hunter was in charge of the ZEBRA installed at STC's research laboratories (Standard 
Telecommunication Eaboratories Etd, or STE) in Harlow from 1960 to 1963. He had earlier 
worked on Edsac I (Society). Hunter was part of the people who installed and first used the 
Stantec-ZEBRA machine. He wrote an article called (The Stantec-Zebra Computer 
Memories of the Zebra). In his article he acknowledged the initial works of WE van der 
Poel. Besides working on the ZEBRA machine van der Poel also worked on Testudo and 
it took 5 years to complete. It could do in 16 hours what we human beings could do in eight, 
if we worked intensively for the whole day. The other one is the Ptera (PTT Electronic 
Reckoning Automat). 

The emulator created by Don Hunter mimics the original ZEBRA. Even though the 
telephone dial, switches, input and output tape and teleprinter are not visible they can still 
be used on the emulator. The input to them is done via key press on the keyboard. All the 
major components are accessed via a sequence of key presses and the result is printed on 
the screen. This emulator is command line based and the help menu can be accessed on the 
emulator by typing the question mark (?). Output is displayed in the same window of the 
emulator and can be transferred to the RESUETS.OUT file by the user by following the 
instructions given in the user manual that comes with the emulator. 

Demonstration programs come with the emulator and these help the user to run them and 

see how the emulator works and its performance efficiency meter which is located at the 
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bottom right of the screen. These programs are written in Normal Code and Simple Code 
the programming languages that were used during that time. Other sophisticated programs 
such as the ACTAB.SRC are provided to show the level of complexity that the emulator 
can handle and how it can perform. 


A more technical and detailed explanation of the emulator can be found online at the 
Computer Conservation Society 

http://www.computerconservationsocietv.org/resurrection/res 11 .htm#e the article written 
by Don hunter. 



Figure 5.1: Alan Man and Don Hunter at work on the Stantec-ZEBRA installed at STL: Image source 
http://www.stlacc.org.uk/docs/computers 03.htm 
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6 EMULATION AND EMULATORS 


Emulation works by handling the behaviour of the proeessor and the individual 
components. You build each individual piece of the system and then connect the pieces 
much like wires do in hardware. Emulation in itself is broad and can be categorised into 
software emulation and hardware emulation (How do emulators work and how are they 
written, 2016). There is strong dependency between hardware and software and this 
introduces a risk. If one of these fails, it will have influence on the computer’s operation 
and its capabilities. Emulation comes into play by providing a solution to this problem. 

As described by (What is Emulation, no date), “emulation is best described as imitating a 
certain computer platform or program on another platform or program. In this manner, it is 
possible to view documents or run programs on a computer not designed to do so. An 
emulator is itself a program that creates an extra layer between an existing computer 
platform (host platform) and the platform to be reproduced (target platform).” An 
individual may not be concerned by imitation the actual performance or time measures of 
hardware or software but so long as the end product acts as required then it is deemed as 
successful emulation. 

Emulation can also be seen as a means of digital preservation and it focuses on recreating 
the original computer environment. Emulation is difficult, this is because developing an 
emulator is a precise and time-consuming task and especially because the emulated 
environment must appear authentic and must function accurately too. The Church-Turing 
thesis also implies that emulation can be quite difficult, particularly when the exact 
behaviour of the system to be emulated is not documented and has to be deduced through 
reverse engineering (Emulator, 2016). 

Emulation allows a user to have access to any kind of application or operating system on a 
current platform, while the software runs as it did in its original environment. 
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6.1 Benefits of emulation 

• Potentially better graphies quality than original hardware. 

• Potentially additional features original hardware didn't have. 

• Emulators maintain the original look, feel, and behaviour of the digital object, 
which is just as important as the digital data itself. 

• Despite the original cost of developing an emulator, it may prove to be the more 
cost efficient solution over time. 

• Emulators allow software exclusive to one system to be used on another. Eor 
example, a PlayStation 2 exclusive video game could be played on a PC using an 
emulator. 

6.2 Shortcomings of emulation 

• Due to intellectual property rights, some information is lost in a preservation with 
little supporting documentation due to the proprietary nature of the hardware and 
software. 

• Copyright laws are not yet in effect to address saving the documentation and 
specifications of proprietary software and hardware in an emulator module. 

• Emulators are often used as a copyright infringement tool, since they allow users 
to play video games without having to buy the console, and rarely make any attempt 
to prevent the use of illegal copies and this leads to a number of legal uncertainties 
regarding emulation, and leads to software being programmed to refuse to work if 
it can tell the host is an emulator. 

• Emulators require better hardware than the original system has. 
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6.3 Types of Emulators 

There are so many types of emulators and it all depends on which angle you look at them. 
Some emulators are accurate to the core, in terms of clock timing and processing speed and 
most of them are just developed as a reminder of what used to be and placed in museums 
for example. Most common types of emulators are game emulators. Game emulators are 
available for some of these platforms Nintendo, Sony, Microsoft, Sega and Arcade. Popular 
games like Donkey Kong have been emulated and are being enjoyed by those who used to 
play the game in its popular days. 

Some other emulators come as educational tools such as the Android emulator that comes 
with Microsoft Android Software Development kit and some come as alternatives and 
placeholders for the original. Examples include the Blue Stakes and MS Dos. 

6.4 What Emulators achieve 

Emulators are designed to carry out a specific task and that task is tailor made to the 
requirements that initiated its creation. This thesis will focus on the historic uses of 
emulators and these include: 

• drive detailed historic analyses to discover and understand designs for computers 

• They record inconsiderable detail machines 

• They restore an operational understanding of machines and are a tool for 
investigating questions about the machine and its software 

• A tool for historical research for technological developments 

SUMMARY 


Part III of this thesis talks about the Eiterature review and highlights on simulators and 
emulators stating their differences. Eocus is also given on the emulator that was developed 
by Don Hunter which is available on the Computer Conservation Society website. This 
emulator is a replica of the original ZEBRA computer but it need some extra code to be 
written to the Simple Code program for it to run a program properly. On this section, a 
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history of the need for understanding native software and programming languages is given 
so that readers are well aware of the need of knowing how early programmers thought and 
plans they had for the future they anticipated. 
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Part IV 

Project development 


> Chapter 7: GETTING STARTED 

> Chapter 8: METHODOLOGY 

> Chapter 9: TECHNOLOGY 

CHOICES 

> Chapter 10: PROJECT PLAN 
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7 GETTING STARTED 


This thesis will focus on improving/modifying some of the information that was delivered 
in the first report which gave an overall view of the project. The aim is to write a running 
program for the Stantec-ZEBRA computer. The objective is to build a program that is able 
to run the basic programs and implement the functions that the original ZEBRA machine 
performed. The target is to be able to create a running program and having all of the basic 
commands functioning properly. 

7.1 Refinements/Changes to proposed solution 

The initial target for this project was to have as many programs as possible being developed 
and coded by the student and having to demonstrate them working. This requirement has 
not changed. In addition, there can be given an explanation for the demo programs created 
by Don Hunter as a means of showing that the student has understood the Simple Code 
programming language. 

This project is also going to solely focus on Simple Code. Simple Code uses some of the 
features and procedures of Normal Code (Ord-Smith, 1960). However, normal Code is 
mentioned in passing and there is no demonstration of its code and functionality. Since the 
ZEBRA computer is a calculator, mathematical problems will be solved using the Simple 
code. This will demonstrate how much level of understanding the student has attained. 
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8 METHODOLOGY 


The methodology of ehoiee for the development of the programs is influeneed by the 
already existenee of a produet (ZEBRA DOS emulator). The product is there and it has 
gone through the product life cycle phases which are: Development, Introduction, Growth, 
Maturity and Decline/Death. Not focusing though on the sales of this product, the ZEBRA 
DOS emulator will be in its maturity phase heading to the decline phase. 

There are multiple choices for methodologies that will suit the development of the ZEBRA 
emulator and these include: 

• Waterfall development 

• Prototyping 

• Spiral development 

• V shape model 


8.1 Waterfall development 

In a waterfall model, each phase must be completed before the next phase can begin and 
there is no overlapping in the phases. It is also referred to as the linear-sequential life-cycle 
model. It is mainly centred on verification - are we building the right software, and 
validation - are we building it right. The phases found in the life cycle include Requirement 
Gathering and analysis. System Design, Implementation, Integration and Testing, 
Deployment of system, and Maintenance. You cannot proceed to the next phase before the 
previous one is complete and at each phase a document has to be produced. Although this 
model is suitable for small projects it would not be suitable for the program design in 
Simple Code for the ZEBRA since user involvement is key in its development and 
requirements are likely to change during development process so going back up a phase to 
make changes to a specification will be really difficult. 
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8.2 Prototyping 

This model refers to building software applieation prototypes whieh display the 
functionality of the product under development but may not actually hold the exact logic 
of the original software. With this model multiple designs are made for the interface and as 
they are presented some of them will be taken off while some of them will be accepted for 
further improvement. Some of the phases in this model include Basic Requirement 
Identification, Developing the initial Prototype, Review of the Prototype, and Revise and 
enhance the Prototype. This model focuses more on user involvement and it goes through 
the requirements until they are met due to the number of prototypes that will have been 
developed. 

This model is good for the design of the programs that will run on the ZEBRA, however, it 
is mainly concerned with developing blue or pseudo codes. These pseudo code gives a 
logical description in detail with all the steps but it will be written in English so that users 
understand how the logic works. This is not the aim of this project. Pseudo codes are helpful 
but the English language that will be written will not work if it is used as code for the 
machine. Rather a second option will be survivable in order to come up with the final 
running programs for the ZEBRA computer. 

8.3 Spiral Development 

Spiral model is a combination of iterative development process model and sequential linear 
development model; waterfall model with very high emphasis on risk analysis. The spiral 
model has four phases and a software project repeatedly passes through these phases in 
iterations called Spirals. These phases include Identification, Design, Construct or Build, 
and Evaluation and Risk Analysis. This model is suited to complex projects and those that 
have requirements that are ever changing and which are undertaken in a turbulent 
environment. 

This model is fairly suited to all sorts of projects but the major disadvantage for it towards 
the development of the ZEBRA Simple Code program that management for the project will 
become very costly and complex. Having the project go through many iterations for risk 
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and design and identification will take much of the development time. Just by having the 
specifications clearly labelled out it will be more than enough for the system to be 
developed successfully. 

8.4 V shape model 

V model is an extension of the waterfall model and is based on association of a testing 
phase for each corresponding development stage. This means that for every single phase in 
the development cycle there is a directly associated testing phase. The next phase only starts 
when the previous phase is done. The corresponding testing phase of the development phase 
is planned in parallel so there are verifications on one side of the V and validations on the 
other side. Coding phase joins the two sides of the model. The phases found in this model 
include Business Requirement Analysis, System Design, Architectural Design, Module 
Design and Coding which is the pivot between verification and validation. The phases 
above are the verification phases and the validation phases include Unit Testing, Integration 
Testing, System Testing, and Acceptance Testing. 

The advantage of V model is that it is very easy to understand and apply. The simplicity of 
this model also makes it easier to manage. However, considering the ZEBRA project there 
is a high risk that the project will not be rigid and that even clearly specified specifications 
will not remain the same. Once the application is in the testing stage, it is difficult to go 
back and change a specific function. Flexibility is clearly missing in this model. 

Having stated the models and outlined their pros and cons, the ZEBRA development project 
will be highly suited with the User centred design model/framework. Although the Spiral 
model will have been a great fit for the project, this project is designed focusing on the 
needs of particular users and these users included Professor John Tucker and Rod 
Delamere. These users have an emotional attachment towards it and to use other models to 
develop the system will be a big risk because these models may not accommodate the 
personal needs of these users. Also these users have sufficient knowledge of this machine 
including Mr. Don Hunter and Mr. Noel Cox who are one of the few people to be in physical 
contact with the machine and used it during its time and also learnt its programming 
language. 
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8.5 User Centred Design 

User-centered design (UCD) also known as User-Driven Development (UDD) is a 
framework of processes in which the needs, wants, and limitations of end users of a product, 
service or process are given extensive attention at each stage of the design process (User- 
centered design, 2016). The focus on UCD is to get as much detail as possible from the 
users. First-hand information from them and not to make assumptions and in the end 
making a product/software that will not confirm to their expectations. According to (Travis, 
2015), design is based upon an explicit understanding of users, tasks, and environments. It 
is driven and refined by user-centred evaluation, and addresses the whole user experience. 
The process involves users throughout the design and development process and it is 
iterative in nature. 

There are some general phases in a UCD framework and these include: 

• Specify the context of use: Identify the people who will use the product, what they 
will use it for, and under what conditions they will use it. 

• Specify requirements: Identify any business requirements or user goals that must be 
met for the product to be successful. 

• Create design solutions: This part of the process may be done in stages, building 
from a rough concept to a complete design. 

• Evaluate designs: Evaluation - ideally through usability testing with actual users - 
is as, integral as quality testing is to good software development. 

There are many variations to the UCD framework and this makes it flexible enough to be 
incorporated into the other trademark software development models. The one big advantage 
of using UCD is that it is cheap to use. There are no complicated steps to go through and 
no need for a fairly large number of people within a team. The goal here is to get enough 
from the user and that these users participate fully during the development of the software 
so that what they mention is what they get. 

The chief difference from other product design philosophies is that user-centred design tries 
to optimize the product around how users can, want, or need to use the product, rather than 
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forcing the users to change their behaviour to accommodate the product (User-centred 
design, 2016). 
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9 TECHNOLOGY OF CHOICE 


The technology of choice to be used for the development of the Stantec-ZEBRA program 
is the Simple Code language. Although there can be an option of using assembly language, 
this will be a very difficult task indeed because there are some built in/hard coded functions 
in the form of mathematical equations that are not mentioned in Ord-Smith’s article and by 
Don Hunter. This thesis will focus on C and Assembly vs the Simple Code language and 
give reasons why this language was the number one contender over others. 


Table 9.1: Comparison of C, Assembly and Simple Code in relation to ZEBRA program development 


Topic 

C 

Assembly 

Simple Code 

Architecture 

It is a structured 

It is a structured 

It is a structured 


programming 

programming 

programming 


language and 

language and very 

language; earlier to 


knowledge for 

low level with 

Assembly and has 


header files is 

ability to move 

inbuilt functions to 


important to make 

values directly in 

run with Normal 


use of functions 

memory 

Code 

Memory 

Manual memory 

Manual memory 

Memory 

management 

management, when 

management, when 

management is 


using variables. 

using variables. 

automatically done 


input data must not 

input data must not 

by the computer 


exceed the variable 

exceed the variable 

since every entry is 


size otherwise 

size otherwise 

converted directly 


buffer overflow and 

buffer overflow and 

into floating point 


overwriting of stake 

overwriting of stake 



memory will occur 

memory will occur 


Error handling 

Minimum error 

Minimum error 

Very difficult to 


handling as 

handling as 

error handle code; 


programmer has to 

programmer has to 

when error occurs 


write correct code 

write correct code 

the computer just 
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otherwise the 

program will crush 

otherwise the 

program will crush 

stops and 

programmer has to 

go over the code and 

find out why it did 

not run properly 

Execution speed 

Fast executions time 

as it is more closely 

linked to machine 

code 

Very fast execution 

time as it is linked 

directly to machine 

code 

Very fast execution 

time as it is linked 

directly to machine 

code and uses only 

floating point values 

Support for other 

languages 

Integration with 

other languages at 

the lower level is 

easy 

Integration with 

other languages at 

the lower level is 

easy 

Integration with 

other languages is 

very difficult 

because of the 

missing information 

on Normal Code 

Debugging 

Very hard to debug 

programs since it is 

structured an error 

may be flag on a 

line that will have 

correct syntax when 

in actual effect the 

error occurred on a 

different line 

Very hard to debug 

programs and must 

have knowledge of 

movement of data 

from one register to 

another 

Very hard if not 

impossible to 

debug; full 

knowledge of the 

code is needed in 

order to be able to 

debug at any point 

in the program 

Interoperability 

Programs 

developed using the 

C language can be 

run on any platform 

Programs 

developed using the 

Assembly language 

can be run on any 

platform 

Programs 

developed using 

Simple Code only 

run on the Stantec- 

ZEBRA computer 
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Support for GUI 

C language at 

Assembly language 

Simple Code has no 


programming level 

at programming 

support for 


has little or no 

level has little or no 

incorporating GUI 


support for GUI. 

support for GUI. 



Interaction is 

Interaction is 



command line based 

command line based 



Simple Code was ehosen as the technology of choice for this project. Although, Assembly 
language is fairly similar to Simple Code in terms of moving values directly from one 
memory location to another, Simple Code has the ability to call Normal Code which is used 
for mathematical operations using the operator Z19. In order to use Assembly language and 
C language there is a disadvantage in that one has to understand the code that was written 
to develop the ZEBRA computer. This language is PASCAL. 

A line by line interpretation will be needed for the code in order to understand how the 
computer takes in the Simple Code and switch over to Normal Code for its mathematical 
operations. The C language also has the problem of memory overflow when a value too big 
is specified it overflows from one memory location into another and this will cause many 
errors to occur that are complicated to fix. This is highly possible to happen using the 
ZEBRA because it only works with floating point numbers and there is a risk that values 
may be truncated or lose its significance by a certain percentage. So it is safer not to 
translate the PASCAL code and just use the Simple Code instead. 
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10 PROJECT PLAN 


This phase of the project mainly focuses on how resources are to be allocated towards 
development and how time will be managed throughout the course of development. The 
planning aspect is the pinnacle for success for any activity that requires management. 
According to (Gunder, 2003), planning in itself is the process that identifies the goals or 
objectives to be achieved, formulates strategies to achieve them, arranges or creates the 
means required, and implements, directs, and monitors all steps in their proper sequence. 

A project is said to be successful when it has met its requirements. These requirements 
make up the goals of the project and the major goal of this project is to develop a fully 
functional written program for the Stantec-ZEBRA machine. In order to achieve this, a set 
of deliverables have to be outlined. These act as the milestones so that progress can be 
monitored properly. The set of deliverables for the project includes: 

• To master software engineering tools and methods and programming in Simple 
Code language. 

• To understand fine details of computer architecture and memories and machine 
code programming. 

• To write a program in Simple Code that can run on Don Hunter’s Stantec-ZEBRA 
emulator. 

These are the high level deliverables that are generalised and which touch across all the 
aspects of the project. The low level deliverables include: 

• Eearning the Simple Code language in order to write a running program on Don 
Hunter’s emulator. 

• Understand sample codes written by Don Hunter as a way of showing that the 
student fully understands Simple Code. 

• Completing the project before the end of the month of September in order to meet 
the University deadline 
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Deliverables for them to be effective they need to be given estimated start date and end date 
and these may be gradually updated during the course of the project. The estimated dates 
and time frames for the deliverables will be given in the Gantt Chart in figure 10.2. Gantt 
charts illustrate the start and finish dates of the terminal elements and summary elements 
of a project. This plots the time to be taken versus the deliverables or the task to be 
accomplished. Below is the Work Breakdown Structure (WBS) that will be taken in order 
to fulfil project objectives: 



Figure 10.1: Project WBS 
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ID 

WBS 

Predicessors 

Duration 

Weeks 

Weeks 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 


Leamirtg commands 


3 


2 

Learning language supported 


5 


3 

Learning programming language 

1 

7 


4 

Designing the programs 

2 

2 


5 

Documentation 

1 

9 


6 

Code implementation 

2 

10 


7 

Vizualization of the original m^hine 

3 

2 


8 

Testing modules 

3 

7 


9 

Raising awareness 

6 

2 








Figure 10.2: Project Gantt Chart 

The Gantt chart above shows the dependencies and the duration that each and every task is 
expected to take. The tasks are in the form of WBSs and the estimated durations are listed 
in weeks required to be spent on each and every task. 

The tasks which take the least amount of time which is 2 weeks are Learning commands, 
Designing the programs, Visualization of the original machine and Raising awareness for 
the need of such emulators to the public. The tasks that are expected to take up much of the 
time are writing the documentation and actual coding of the programs which takes 9 and 
10 weeks respectively. These are the core activities and thus take about 70% of the duration 
of the planned time to finish the project. The estimated duration of completing the project 
is 17 weeks and this starts from June 2016 to mid-September 2016. 

The initial tasks are Learning commands and Learning language supported, thus they have 
no predecessors. After Learning the commands, the next activity is Learning the 
programming language and this is expected to start whilst still the student is learning the 
Language supported. At the same time code implementation is expected to start at the same 
time with Learning the programming language. 

Testing of the system is set to start after the Learning programming language is complete 
and for it to be successful it will be done during code implementation as well. 
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10.1 Basic Risk Analysis and Management 

Risk is defined as the possibility that something bad or unpleasant will happen. Risk eannot 
be anticipated or predicted when it will occur but there are strategies that will help in 
formulating plans and proper measures of guarding against the effects of risk. This thesis 
will use the notion of using the key elements of risk management placing them in a table 
format, identifying the risk, assessing it, monitoring it and suggesting ways to control or 
mitigate the effects of the risk. 

The scale used for calculating the probability of occurrence of a risk runs from 1-5 and 1 
meaning that there is a low probability for the risk to happen. The value 3 represent the 
mid-point that the risk can either happen or not and it will depend if it can be placed under 
a priority concern or not. The value 5 represents the highest value that the risk may happen 
and this will require more attention and monitoring during the development of this project. 

Table 10.1: Risk Management 


Risk 

Assessment of 

risk 

Monitoring the 

risk 

Controlling the 

risk 

Probability of 

occurrence 

(scale 1-5) 

Methodology of 

The 

When duration 

Having to take 

2 

choice not 

methodology 

stated in Gantt 

out some of the 


appropriate 

used for the 

chart exceeds 

activities in 



development of 

for 

the 

order to meet 



this program 

development of 

project 



may be too 

the of 

the 

requirements 



complicated 

program. 

this 




and require too 

will be 

the 




much effort to 

warning of the 




be put in 

methodology 





having failed to 





meet the needs 





of the project 
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Technology of 

choice is not 

meeting 

requirements 

The technology 

may not be able 

to implement 

some of the 

features and the 

functions of the 

original 

command line 

emulator 

Make sure that 

functions meet 

the technology 

available 

Remove 

features and 

functions that 

will be difficult 

to implement in 

project 

development 

3 

Understanding 

This is a major 

Check learning 

Try to put in 

3 

and 

factor that can 

progress 

more effort in 


implementing 

lead to the 

against the time 

order to 


Simple Code 

failure of 

stipulated on 

understand the 


language 

meeting project 

the Gantt chart 

language 



goals and 

to find out if 

because 



objectives 

task time has 

without 




not exceeded 

knowledge of 




original 

the language 




amount of time 

then coding 




planned for 

cannot occur 





together with 





development 


Time 

Time is a big 

Milestones 

A pre- 

4 

management 

factor in the 

have to be met 

allocation of 5 



success of any 

before deadline 

days has been 



project and 


placed on every 



milestones 


activity to 



have to be meet 


allow for any 



before the 


complications 



deadline 


that may allow 



because if the 


a milestone to 
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overlap into 

other activities 

it will cause 

problems in 

development 


be extended its 

delivery time 


Illness and 

personal 

problems 

This will have a 

small impact in 

terms of 

affecting the 

success of the 

project unless it 

is something 

life threatening 

Stick to 

planned 

schedules and 

take regular 

breaks 

Plan to always 

take a day or 2 

off for resting 

and 

recuperating in 

order to 

maintain the 

project flow 

3 


10.2 Testing/Evaluation Plan 

The testing of software is an important means of assessing the software to determine its 
quality. The general aim of testing is to affirm the quality of software systems by 
systematically exercising the software in carefully controlled circumstances. The goal of 
testing is to find an undiscovered error and a successful test is one that uncovers an as yet 
undiscovered error. Testing is involved in every stage of development but the testing done 
at each level of software development is different in nature and has different objectives. 

Unit Testing is done at the lowest level which is the smallest testable piece of software and 
it is often called a unit. Integration Testing is performed when two or more tested units are 
combined into a larger structure. System test is often based on the functional/requirement 
specification of the system and non-functional quality attributes are also checked. 
Acceptance Testing is done when the completed system is handed over from the developers 
to the customers or users. 

The testing strategy that is going to be used for the project is black-box testing. This is the 
technique of testing without having any knowledge of the interior workings of the 
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application. The tester is looking at the system architecture and will not have access to the 
source code. While performing a black-box test, a tester will interact with the system's user 
interface by providing inputs and examining outputs without knowing how and where the 
inputs are worked upon. 

This test strategy is best suited for the project in the fact that what is required of the student 
is to be able to write a program that will run on the ZEBRA emulator available on the 
Computer Conservation Society website. Understanding of the code is really crucial but the 
way in which Normal Code is integrated and how Normal Code is written is not part of the 
focus for this project. 

SUMMARY 


The aim of this report is to give a detailed overview of the project. Giving a brief 
introduction to the problem and picking up the methodology to be used in order to 
accomplish the task of designing the emulator made up part of the main core of this report. 
A project evaluation plan was given and this focused on how time and resources will be 
managed through the use of a Gantt chart and a work break down structure. This project is 
not intended to be sold and it is meant to be an open source software, therefore, budgeting 
and finance was not included in this report. The technologies to be used for the development 
of this project is Simple Code and it was compared and evaluated against other existing 
technologies to justify its choice as the main technology to be used. Finally, an assessment 
of the possible risks that might occur was given and strategies were given on how to 
mitigate then and a scaling factor was given on the probability of the risk occurring and 
whether it should be priorities or not. 
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11 RESULTS AND ANALYSIS 


In this chapter the focus is on the outcome of the dissertation as a whole. Emphases will be 
on whether the requirements and specifications of the project were met. This chapter also 
gives the author the opportunity to mention the major challenges faced and evaluate the 
effects of stated challenges and what methods/approaches were taken to overcome these. 

11.1 Installing the ZEBRA 


The Stantec-ZEBRA emulator developed by Don Hunter is available for download from 
the Computer Conservation Society. Since technology has changed drastically over time, 
the ZEBRA was written to be run on MS-DOS or PC-DOS platforms so there is a high 
chance that by installing the emulator and trying to run it on Windows 7 and earlier versions 
will prompt the following errors messages (Computer conservation society, no date): 



Figure 11.1: Possible error message 1: Image source 

http://www.computerconservationsocietv.org/software/dosboxnotes.htm 
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Figure 11.2: Possible error message 2: Image source 

http://www.computerconservationsocietv.org/software/dosboxnotes.htm 


This app can't run on your PC 

To find a version for your PC, check with the software publisher. 


Close 


Figure 11.3: Possible error message 3: Image source 

http://www.computerconservationsocietv.org/software/dosboxnotes.htm 

The error messages above show that there is a problem that is encountered with running 
these DOS programs on early computers. It is either that the program is not compatible on 
64bit computers or when it is 32bit it will not support full screen mode. On windows 10 it 
will completely not run and prompt you to find a version of a PC that is compatible to the 
program. 

There is, though, a measure of going around this and it is to download and install DOS- 
BOX which provides a DOS environment for the DOS programs to run. The DOX-BOS 
program is available for download at http://www.dosbox.com/ . After downloading and 
installing the DOS-BOX the second step will be, after extracting the contents of the DOX- 
BOX setup file into a folder, mount the folder created as a virtual hard drive in DOS-Box. 

To mount the folder on the hard drive, for example C: drive you write the following in 
DOS-BOX: 
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• MOUNT C C:\[path to the folder with ZEBRA] 

• If the folder name is ZEBRA for example, to run the emulator you just type in 
ZEBRA and the emulator will run giving the window below 

• Type in KEYB UK so that the program will use the UK keyboard layout for input 
to the program. 



Figure 11.4: Stantec-ZEBRA emulator running 

11.2 Simple Code file format and running a 
program 

All Simple Code programs must be saved using the .src extension otherwise it will not run 
on the ZEBRA emulator. To write a custom Simple Code program the two best programs 
to do so with are Notepad and Notepad++. To load in a program in the emulator user presses 
the (a) key and prompts to enter the program name as shown below. An example of a 
program named mine4 is entered after the prompt. 
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DOSBox 0.74, Cpu speed: 3000 cycles, Frameskip 0, Program: ZEBRA 


Fast 


ZEBRFI ?=r>enu Choose P/T: nine4 

t.?.???...?. 

t.?.???...♦.?. 

o .oooooo 

U . . Eff.meter: 3.lx 


Figure 11.5: Press a and program askes to input PTpaper tape 


To run the program, press/7 twice and the output from computation will be printed top left 
to the ZEBRA ?=menu as shown below: 
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Figure 11.6: Output of computation on mine4.src Simple Code program 

The dots on the A:, B:, C: and D: lines signify that memory address is empty/off and the 
question marks means that it has a value/on. NC & SC dial is a prompt to enter a value from 
the range of 1 - 9 as if you are entering it from a telephone dial. This feature is not used in 
this dissertation. 

11.3 Demo programs 

The requirements and specifications of this project were met. The student managed to write 
his own programs using the Simple Code language. The language is said to be derived from 
the Edsac I instruction set with the addition of index registers, labels, many built-in 
functions, a trace facility and nine digit floating point arithmetic and is approximately dated 
from 1950-55 (Society, no date). 
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11.3.1 Demo 1 

The program takes in a value c, multiplies it by the value a, and takes the result of {c*a) 
and adds it to b^. a = 2,b = 3, c = 4, A is the accumulator. The Simple Code for this program 
is given below: 

00000 

Y 

L {a = +2} 

LI {b = +3} 

L2 {c = +4} 

-00 {4 decimal digits and no sign} 

+00 {no decimal point} 

Z30 

H2 (move c into A: A contains 4} 

Y (A * n = A: n holds the value +2 therefore, A = 8} 

VOl (A + (n+l)2 = A: (n+1) holds the value +3 therefore, A = 8 + 

9 = 17} 

Z9 (cr If fs} 

Z31 (print A + (n+l)2} 

Z {stop} 

YOO 

+2 a 

+ 3 b 

+ 4 c 

Y 

007000 

The first line in any Simple Code program begins with 00000 and this line signifies the 
beginning of the program. Y signifies the beginning of Simple Code. L, LI, L2, mean read 
number into. L has a container n which takes an input value. Here n = +2, (n+J) = +3 and 
(n+2) = +4. Z30 means output or suppress sign. H2 means move value of L2 into A. V 
means multiply A with n. VOl means A plus (n+J) and store the contains in A. Z9 prints 
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out a carriage return. Z31 prints out the value in A with no decimal point. Z stops the 
computer. YOO comes straight after Z. Values that are written after YOO are the values that 
will be read into n, n+1, etc. Y signifies the end of Simple Code. 007000 specifies the end 
of the program. 

The output of the above program is +17. A full guide of instructions is given in the appendix 
section. 


11.3.2 Demo 2 

Given two sides of a triangle, a = 3 and b = 4 find the hypotenuse c using the Pythagoras 
Theorem c = V (a^ + b^). 

00000 {The first seven lines are the same as explained in the above 

program} 

Y 
L 

LI 
-00 
+ 00 
Z30 
H 

Y 

VOl 

Z1 (V (a2 + b2) } 

Z9 

Z31 

Z 

YOO 
+ 3 
+ 4 

Y 

007000 
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The above program finds the hypotenuse using the Pythagoras Theorem. Given a = 3 and 
b = 4 therefore, V (3^ + 4^) = 5. 

Note that; in any Simple Code program comment are made inside a program using {}. 
Anything that is contained between the opening curly brace {and the closing brace} is a 
comment and is not part of the program. The comments are put inside programs to explain 
to the reader what the program is or what the line of code means. 

11.3.3 Demo 3 

Given a triangle in the figure below, find the value of a. 


C 



3 

Figure W.l: Acute angle triangle, find the value of a 

00000 

Y 

L 


LI 




L2 




L3 




L4 




L5 




H 

{n = 

49} 


Z5 

{cos 

(49) 

= A} 

VI 

{A * 

n+1 

= A} 

V2 

{A * 

n+2 

= A} 

V3 

{A * 

n+3 

= A} 

VO 4 

{A + 

(n+4 

= A} 
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VOS {A * (n+5)2 = A} 

Z1 {Va} 

Z9 

Z8 {print A in floating point form} 

Z 

YOO 
+ 49 
+ 7 
+ 5 
-2 
+ 7 
+ 5 
Y 

007000 

The value of a is supposed to be 5.30 correct to 2 decimal places but the problem is Z5 {cos 
(49)} is providing an answer of 0.300593 on the ZEBRA computer instead of 0.656059, 
therefore, the resulting answer from the ZEBRA is wrong. 

11.4 Assessment and Evaluation 

Booking at the project and comparing the expected results from actual results, it can be 
concluded that the project was a success. Below are the tables for the requirements that 
were stated out and the results that transpired during the course of project development. A 

set of symbols will be used to signify weather the target was met or not using the to 
mean that objective was not met and Z to show that the objective was met. 

Table 11.1: Requirements against outcomes 


Requirements 

Completed 

Description 

Simple Code 

program 

Z 

Provided in this thesis are 3 running examples of 

mathematical problems. 
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Must run on the 

ZEBRA 

emulator 

y 

The three mathematical problems are successfully 

running on Don Hunter’s ZEBRA emulator. 

Key words to 

be used as 

commands to 

the program 

y 

The key words are the subroutines and procedures that 

are used in the creation of Simple Code programs and 

they were used properly in the programs 

Interpret 

sample 

programs 

y 

The student is able to interpret some of Don Hunter’s 

programs but the majority is Normal Code and is 

difficult to interpret since information on Normal Code 

is not available 


In terms of progress analysis using the WBS and the Gantt ehart, all the steps exeept for 
one was omitted in the WBS which is the physical visualization of the ZEBRA computer. 
This did not manage to happen but the student got the opportunity to meet face-to-face with 
one of the few people to have used the original ZEBRA computers from the 1950s Mr. Rod 
Delamere. He gave an explanation on what the computer was used for and how the 
programming language was named Simple Code but yet it was not that simple at all. 


With regards to the Gantt chart, changes had to be made in order to finish the project on 
time. The actual way in which the activities were carried on with looked like this in the end 
as compared to the planned one under the Project Plan section. 


ID 

WBS 

Predicessors 

Duration 

Weeks 

Weeks 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 

1 

Learning commands 


12 


2 

Learning language supported 


10 


3 

Learning programming language 


12 


4 

Designing the programs 


2 


5 

Documentation 


14 


6 

Code implementation 


11 


7 

Vizualization of the original machine 


0 


8 

Testing modules 

2 

7 


9 

Raising awareness 

3 

2 








Figure 11.8: Actual activities and the days taken to complete them shown in revised Gantt Chart 
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The writing of the documentation took more than 80 percent of the time and this was the 
biggest challenge faced by the student. This was followed by learning the commands and 
the programming language. This had a factor on having the documentation being so long 
because the student could not start anything before he had a clear mind of the Stantec- 
ZEBRA computer. 

This proved to be a huge challenge because even the Computer Conservation Society was 
not so familiar on how Don Hunter’s simulator worked. Help was eventually acquired from 
Mr. Rod Delamere but still, his notebook from 1950 together with his examples could not 
work on the emulator. This took a lot of time for the student to realise that for a program to 
run on the emulator it requires some additional lines of code. 

The major challenge and obstacle faced during the project development was understanding 
how the Stantec-ZEBRA works. Up until this point, the student has basic functionality 
understanding of the computer. The fact that debugging the computer is made almost near 
to impossible without any error detecting systems makes using Simple Code very difficult 
to even grasp and write a basic program. Below is the revised table for risks that were 
anticipated and how the student managed to overcome the challenges. 


Table 11.2: Revised Risk Management 


Risk 

Assessment of risk 

Tackling the risk 

Methodology of choice not 

appropriate 

The methodology used for 

the development of this 

program may be too 

complicated and require 

too much effort to be put in 

The methodology of choice 

(User Centred Design) was 

an effective choice because 

there was the right amount 

of interaction between the 

users and the student. 

Technology of choice is not 

meeting requirements 

The technology may not be 

able to implement some of 

the features and the 

functions of the original 

command line emulator 

Simple Code was the 

obvious and only choice 

and it has made the student 

fully understand how to 

program in the language 


UNDERSTANDING THE STANTEC-ZEBRA 


67 









Understanding and 

implementing Simple Code 

language 

This is a major factor that 

can lead to the failure of 

meeting project goals and 

objectives 

Having to understand the 

Simple Code was not an 

easy task. It took most of 

the development time and 

in the end the student 

understood the language 

Time management 

Time is a big factor in the 

success of any project and 

milestones have to be meet 

before the deadline because 

if the overlap into other 

activities it will cause 

problems in development 

Time plans had to be 

changed on a regular basis 

to accommodate the drastic 

changes that occurred due 

to the difficulty in 

understanding Simple 

Code 

Illness and personal 

problems 

This will have a small 

impact in terms of affecting 

the success of the project 

unless it is something life 

threatening 

Thankfully enough there 

were no major illnesses 

witnessed during the 

development of this 

dissertation 
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12 CONCLUSION 


During the course of this project development the student has learnt quite a lot from 
researching, from the supervisor and interacting with the supervisor in order to produce 
what is required. The highlight of the journey was finally getting to speed with the Simple 
Code programming language. This took a long time for the student to grasp as it is a very 
old programming language dating to 1950 and is not even listed on the programming 
languages list on these popular websites http://rigaux.org/language-studv/diagram.html , 
https://www.levenez.com/lang/ and http://hopl.info/images/genealogies/tester-country.jpg . 
Simple Code, however, despite the name is not so simple. This code is a set of subroutines 
that you call using key terms just like how programming works using Assembly language. 

Simple Code works directly with numbers in their floating point form which makes it faster 
for the program to run because there is no need for converting from one form to another 
which takes up time and memory. It also works by referring directly to a memory location 
just like Short Code and Assembly code and this makes it really versatile because you are 
given full control over memory management and have the actual address to every value 
that is stored in the program. 

The biggest challenge that came about using the ZEBRA computer was the problem of 
debugging. This computer has no means of telling the user the reason of it not working or 
where the error is or even what sort of error it is. Mr. Delamere concurred to this when he 
mentioned a story about his encounter with the ZEBRA computer. He said that there was a 
time when he ran a paper tape program into the ZEBRA and at the middle of the tape the 
computer just stopped and by that is was a signal that something had gone wrong. At the 
second attempt he ran the same paper tape and the computer jammed at the same point. At 
that point in time he did not know what to do next so he took a small piece of paper and 
stuck it on one of the holes with bubble-gum in the place where the computer was jamming 
and put back the paper in the computer. At the third attempt, the ZEBRA jammed again but 
after a nudge of the paper it went through and continued its calculations. 

This just shows how hard it was to know what sort of error had effected the computer. It 

was just too hard to know where to start and the student can testify to this as he also 
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encountered the same problem when trying to write a simple program on Don Hunter’s 
emulator. It was a gruelling experience because the emulator also gave away no error 
messages. If the program was wrongly written, for example, the screen would not output 
anything. Then and only then would you know that something is wrong and the best way 
to deal with such a case was to go through the program again line by line to see where the 
problem was. 

In the end, three programs were created that are perfectly running on the emulator. There 
are also many sample programs provided by Don Hunter which show the full power and 
potential that is held within this computer. 

Within the whole journey that the student took on this project, the biggest notable point is 
that, as technology is evolving we are losing our touch on the obscured or depleted software 
and programs. By asking online on the explanations on how the ZEBRA works, most of 
programmers online, especially on Stake Overflow, they did not even know the computer 
later alone the programming language. This shows that preservation of data is important 
and raising awareness on existence of such computers had to be done. It might be outdated 
but by studying it you will get a feel of how early computers worked and it may also inspire 
you in a way that was not even expected. 

As the world becomes increasingly and overwhelmingly dependent on software, we find 
that the core of that software - programming languages and systems - remain a mystery to 
even their users, the programmers. By paying attention to the origin, rise and fall of each 
of the languages we may learn why they made their decisions (The encyclopaedia of 
computer languages, no date). "...Progress, far from consisting in change, depends on 
retentiveness. When change is absolute there remains no being to improve and no direction 
is set for possible improvement: and when experience is not retained, as among savages, 
infancy is perpetual. Those who cannot remember the past are condemned to repeat it. In 
the first stage of life the mind is frivolous and easily distracted, it misses progress by failing 
in consecutiveness and persistence. This is the condition of children and barbarians, in 
which instinct has learned nothing from experience...." (Santayana, 1905). 


UNDERSTANDING THE STANTEC-ZEBRA 


70 




12.1 Recommendations 


It would be a good thing for the eontinuation of this projeet and to design a user interfaee 
for the Stantee-ZEBRA computer. Don Hunter’s emulator is available for download from 
the Computer Conservation Society website but it is a DOS software program. Many people 
are not fa mi liar with using DOS commands, therefore, although the emulator is fully 
functional it will not be an attractive application to contemporary computer users. An 
upgrade to a user-friendly interface will enhance its popularity also just like other emulators 
such as the SSEM and the EDSAC that have user-friendly interfaces that most computer 
users are accustomed to. 


Some work was done by the author regarding the development of a user interface for Don 
Hunter’s Stantee-ZEBRA emulator. Eigure 12.1 below shows the work that was done and 
an individual can pick up form there and finish up the project. 


■ Stantec Zebra — □ X 


File Edit Library Help 


New 

Open 

Close 


ZbBKA 

A; _ 


B: .. 


C: 


Q _i_!.!!!...!__!. 


0 .oooooo 

Fast U. 

Eff.meter 3.1% 


Figure 12.1: Proposed GUI design for Don Hunter's MS-DOS emulator 
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This GUI has been designed using JAVAFX programming language. All of the keys that 
work on the DOS emulator have been given links in the GUI program however, this 
program is not functional. It is the skin of the hard code of the ZEBRA emulator and the 
task will be to interpret Don Hunter’s emulator written in PASCAL and try to integrate it 
with the JAVAFX interface or to redesign the emulator entirely to produce a contemporary 
ZEBRA computer that can be used in this day and age without experiencing any 
unnecessary difficulties. 

An error handling mechanism must also be put in place so as to give users error and warning 
messages when they use the machine in the wrong manner. An addition of the telephone 
dial to the interface will be a great idea so that the full ZEBRA functions will be available 
to the user. 

The second requirement is to embark on a project to reconstruct the ZEBRA in its physical 
form. To reassemble the original parts and try to build the original computer designed by 
van der Poel. A similar project is currently underway for the project to build, demonstrate 
and maintain a replica of the Small-Scale Experimental Machine which is the world's first 
computer and also the Bombe machine. The SSEM is currently being rebuilt and there are 
a number of groups who are helping out with this project. To find out more information on 
these project please visit http://www.cs.man.ac.uk/CCS/SSEM/volunteers/index.html , 
http://curation.cs.manchester.ac.uk/digital60/www.digital60.org/rebuild/ and 

http ://w ww. computerconservationsociet V. or g/w g-bombe .him . 
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APPENDIX II: STANTEC-ZEBRA SIMPLE 
CODE INSTRACTION CODE 


STyViNTEC-ZEBRA SIMPLE CODE INSTRUCTION CODE 


Arithmetic iiutmclioris 


Time in milliseconds 


An 

(A) + (n) .1 

40) 

Sn 

(j) 

401 average 

Vn 

(A) X (n)-*A 

35 J 

Nn 

-(A) X (n}-.A 

35 

Dn 

(A) - («) A 

55 

Tn 

(A) - >n A 

20 

Un 

{A)-*n 

20 

Iln 

(«) A 

20 

Accumulative multiplication uses: 


Kn 

(n) -^ii 

20 

followed immediately by: 


Vn' 

(B) X in') + (.-1) -> A 

55 

or by 

Nn' 

- (B) X in') + (-1) A 

55 

Also provided: 

VOn 

(T) + (»)■' - .1 

55 

NOn 

(•■1) -(«)=- A 

55 


Subroutines (here numbers in brackets 
Z stop, wait for dial or 
Sian key 

ZI V(T) — A (80) 


arc approximate times in millisccs.) 
'/21 ^ (.•!)-> .4 (15) 

Z22 Punch (.-1) in floating form 
Z23 Punch cr Iffs 


I! 
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Z2 

exp (/I) -*■ A (variable) 

Z24 

Z3 

In (Z) -> A 

(150) 


24 

sin {A) -*■ A 

(140) 

Z23 

Z5 

cos (/4) -*• A 

(140) 


Z6 

arctan (^) ^ (v 

ariablc) 

Z26 

Z7 

Test Key U\ 

(15) 


za 

Print {A) in floating 



form 


Z27 

Z9 

‘Print’ crlffs 


Z28 

ZIO 

log {.!) A 

(180) 

229 

Zll 

arccos (.d) -* A 

(500) 


212 

sinh [A) -*■ A 

(360) 


Z13 

cosh (d) -♦ d 

(350) 

Z30 

Z14 

arccosh (d) -► d 

(430) 


Z15 

arctanh (d) —* d 

(400) 


Z16 


(30) 


Z17 

iW-^A 

(20) 


218 


(15) 

Z31 

Z19 

Jump from S.C. 

to 



N.C. 



Z20 

' Special counting 

(15) 



facility 




floating form 
Floating'point number 
in fixed form 
Punch or print space 
(which and the number 
depends on («)) 


(13) 


form according to 
pattern 

Set fixed'poim pattern. 
(Can output or suppress 
sign and describe num¬ 
ber tff digits before and 
after point) 

Print (^) in fixed-point 
form according to pattern. 


Z32-Z63 can also be used and wilt contain subroutines peculiar to 
the needs of a particular user, i.c. these call-in instructions can be changed 
to meet particular requirements. 

lnp\ii\ouiput inslniclions 


Time in milliseconds 
10 mscc/digit -(- 40 msec/number 
10 mscc/dtgii -f- 25 msec/number 


Ln Read number —► n 
LOn Read numbers -> n, n + 1, 

. . . terminated with a Y 
Pn Print (n) 

POn Punch («) 

See also Z8, Z9, Z22, Z23, Z26, Z29, Z30. Z31 in list of subroutines. 

Control instructions Time in 

milliseconds 

, remember return 15 


Xp jump to location labelled p 
instruction in special place 

XRRROp jump to location labelled p, remember return 
instruction in register B 


10 
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XOp place return instruction set by last Xp in 20 
location labelled p 
Qp label location/* 

QOp clear label p 

Ep jump to location labelled p if (/4) ^0, other- 15 

wise proceed serially 

EOp jump to location labelled p if {A) < 0, other- 15 

wise proceed serially 

Input 

Y clear labels (if Y is at the beginning of tape) and begin input at 
the beginning of the instruction store 
Yp begin input at location labelled p 

YOn begin input of instructions in the number store at location n 
YOh' begin input of instructions in the instruction store at location n. 

Execution indication 

YOG begin execution at the place given by last input indication 

Pointed address facilities 

In' number is in instruction location n. 

In'P number is in that instruction location which is the nth relative 
to location labelled p 

(/ is any arithmetic, input or output instruction) 

Relative address facilities 

IRn interpreted as In {*) 

IRRn interpreted as /« -f- {^) 

IRRRn interpreted as /« -j- {*) -f- (yJ) 

R can be atuched to A, S, V, N, D, T, U, H, Ky VO, XO, L, 10, 
P, PO, X, XO, E, EO 

RR can be attached to all the above except XO, E, EO 
RRR can be attached similarly with the further exclusion of X 

Counting facilities 

For details sec text. 

+ On set count to n times 
— On set count to [(a) -t- J] times 

+a count with n at a time 
—« count with {(«) -f- i) at a time 

VOn put count to safety in a 
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HOn 

Also interchange (a) and {fi) 
bring back count from safely 

Also (a) 

-OOn 
+ OOOn 
-OOOn 

(a) —*■ <5 n —► a 

(a) -e d [(w) + i] -*• * 

« —*• y 

[(«) + i] y 


Z20 Increase running count and count limit 

Additional facilities 

DOn exponent (A) + exponent (n) -*■ ex|X)nent {A) 

DOOOOOn exponent {A) — exponent («) —*■ cx^Jonent (>^1) 
—RRn (a) floating—► n 
A' followed 

by numbers input of numbers with instructions 


QZ 

QOOn 

stop during input and begin again with start key 
jump to drum location n during input. This allow's change 
from S.C, input to N.C. execution to take place 

UOOO 

QOOOn 

A'43P 

immediately 

jump to drum location = {a)l enable jump from S.C. to 
jump to drum location n | N.C. 

Normal Code instruction allows jump back to S.C. after 
exit with UOOO or QOOOn. 

.V38P 

ZI9 

Normal Code instruction allow's jump from N.C. to S.C. 
Simple Code subroutine allows jump back to N.C. after exit 
with X38P 

I 

written after Simple Code instruction gives ‘cut-open’ 
facility (see text) 
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